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1  Project  Goals  and  Rationale 

This  curriculum  development  project  had  as  its  primary  goal  the  development  of  a 
course  that  augments  existing  undergraduate  software  curricula  by  teaching  concepts, 
techniques,  and  examples  at  the  architectural  level  of  software  design.  Specifically, 
Architectures  for  Software  Systems  would 

•  Teach  students  how  to  understand  and  evaluate  designs  of  existing  software  sys¬ 
tems  from  an  architectural  perspective. 

•  Provide  students  with  the  intellectual  building  blocks  for  designing  new  systems  in 
principled  ways  using  well-understood  architectural  paradigms. 

•  Show  students  how  formal  notations  and  models  can  be  used  to  characterize  and 
reason  about  a  system  design. 

•  Familiarize  students  with  concrete  examples  of  actual  system  architectures  that 
can  serve  as  models  for  new  designs. 

This  course  not  only  adds  innovative  material  to  existing  curricula,  but  also  helps  to 
define  the  field  of  software  architecture  by  organizing  and  regularizing  the  concepts  and 
by  enabling  the  education  of  software  designers  in  those  concepts. 


2  Results 

We  augmented  the  undergraduate  software  engineering  curriculum  at  Carnegie  Mel¬ 
lon  University  by  developing  a  new  course,  Architectures  for  Software  Systems.  This  in¬ 
volved  four  specific  activities: 

1 .  Creation:  In  the  semester  preceding  the  teaching  of  the  course  we  developed 
the  course  syllabus,  lectures,  homework,  exams.  The  syllabus  was  drawn  from 
an  extensive  bibliography  of  readings.  The  lecture  sequence  was  designed  to 
balance  theoretical  and  practical  concerns.  Homework  was  chosen  to  em¬ 
phasize  basic  skills  of  architectural  design.  Solutions  to  assigned  homework 
were  prototyped. 

2.  Teaching:  We  delivered  the  course  as  an  undergraduate  elective  at  Carnegie 
Mellon  University  to  about  20  students. 

3.  Evaluation:  We  used  our  experience  of  teaching  the  course  to  evaluate  its  effec¬ 
tiveness,  and  suggest  ways  to  improve  it.  This  resulted  in  a  revised  course, 
which  was  taught  in  the  Spring  of  1993,  taught  to  18  students. 

4.  Dissemination:  We  disseminated  the  results  of  our  work  in  several  ways 

•  We  wrote  a  paper  describing  and  evaluating  the  course:  "Experience  with 
a  Course  on  Architectures  for  Software  Systems’.  The  paper  was 
presented  at  the  SEI  Conference  on  Software  Engineering  Education  in 
October  1 992,  and  appears  in  Proceedings  of  the  Sixth  SEI  Conference 
on  Software  Engineering  Education,  Springer-Verfag,  LNCS  376.  This 
report  is  also  available  in  technical  report  form  as  CMU/SEI-92-TR-17. 

•  We  are  currently  packaging  the  course  materials  as  a  unit  for  public  dis¬ 
tribution.  These  will  be  available  as  a  CMU  technical  report  within  the  next 
month. 
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•  We  developed  a  short  form  of  the  material,  suitable  for  half-  and  full-day 
tutorials.  This  material  was  delivered  at  the  following  conferences:  Sof- 
ware  Engineering  and  Knowledge  Engineering  (SEKE’92),  International 
Conference  on  Computer  Aided  Design  (ICCAD’92),  International  Con¬ 
ference  on  Software  Engineering  (ICSE  15).  It  will  be  delivered  again  in 
December,  1993  as  an  invited  tutorial  for  SIGSOFT93. 

•  We  produced  a  paper  based  on  the  course  content  as  a  general  introduc¬ 
tion  to  software  architecture.  The  paper  has  been  published  as  "An  Intro¬ 
duction  to  Software  Architecture",  by  David  Gartan  and  Mary  Shaw,  and 
appears  in  Advances  in  Software  Engineering  and  Knowledge  Engineer¬ 
ing,  Volume  I,  World  Scientific  Publishing  Company,  1 993. 
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Abstract.  As  software  systems  grow  in  size  and  complexity  their  design  problem 
extends  beyond  algonthms  and  data  structures  to  issues  of  system  design.  This  area 
receives  little  or  no  treatment  in  existing  computer  science  curricula.  Although  courses 
about  specific  systems  are  usually  available,  there  is  no  systematic  treatment  of  the 
organizations  used  to  assemble  components  into  systems.  These  issues  -  the  software 
architecture  level  of  software  design  -  are  the  subject  of  a  new  course  that  we  taught 
for  the  first  time  in  Spring  1992.  This  paper  describes  the  motivation  for  the  course, 
the  content  and  structure  of  the  current  version,  and  our  plans  for  improving  the  next 
version. 


1  Overview 

The  software  component  of  the  typical  undergraduate  curriculum  emphasizes  algorithms  and 
data  structures.  Although  courses  on  compilers,  operating  systems,  or  databases  are  usually 
offered,  there  is  no  systematic  treatment  of  the  organization  of  modules  into  systems,  or  of  the 
concepts  and  techniques  at  an  architectural  level  of  software  design.  Thus,  system  issues  are 
seriously  underrepresented  in  current  undergraduate  programs.  Further,  students  now  face 
a  large  gap  between  lower-level  courses,  in  which  they  leant  programming  techniques,  and 
upper-level  project  courses,  in  which  they  are  expected  to  design  more  significant  systems. 
Without  knowing  the  alternatives  and  criteria  that  distinguish  good  architectural  choices, 
the  already-challenging  task  of  defining  an  appropriate  architecture  becomes  formidable. 

We  have  developed  a  course  that  will  help  to  bridge  this  gap:  Architectures  for  Software 
Systems.  Specifically,  the  course: 

-  teaches  how  to  understand  and  evaluate  designs  of  existing  software  systems  from  an 
architectural  perspective, 

"  Development  of  this  course  was  funded  in  pvt  by  the  Department  of  Defense  Advanced  Research 
Project  Agency  under  gram  MDA972-92-J-1002.  It  was  also  funded  in  part  by  the  Carnegie  Mellon 
University  School  of  Computer  Science  and  Software  Engineering  Institute  (which  is  sponsored  by 
the  U.S.  Department  of  Defense).  The  views  and  conclusions  contained  in  this  document  are  those 
of  the  authors  and  should  not  be  interpreted  as  representing  the  official  policies,  either  expressed  or 
implied,  of  the  U.S.  Government,  the  Department  of  Defense,  or  Carnegie  Mellon  Univereity. 


-  provides  the  intellectual  building  blocks  for  designing  new  systems  in  principled  ways 
using  well-understood  architectural  paradigms, 

-  shows  how  formal  notations  and  models  can  be  used  to  characterize  and  reason  about  a 
system  design,  and 

-  presents  concrete  examples  of  actual  system  architectures  that  can  serve  as  models  for 
new  designs. 

This  course  adds  innovative  material  to  existing  curricula  on  the  subject  of  software 
architectures,  it  also  helps  define  the  field  of  software  architecture  by  organizing  and  regu¬ 
larizing  the  concepts  and  by  enabling  the  education  of  software  designers  in  those  concepts. 

2  Background  and  Rationale 

As  the  size  and  complexity  of  software  systems  increases,  the  design  problem  goes  beyond 
the  algorithms  and  data  structures  of  the  computation:  designing  and  specifying  the  overall 
system  structure  emerges  as  a  new  kind  of  problem.  Structural  issues  include  gross  organi¬ 
zation  and  global  control  structure:  protocols  for  communication,  synchronization,  and  data 
access:  assignment  of  functionality  to  design  elements;  composition  of  design  elements; 
scaling  and  performance;  and  selection  among  design  alternatives. 

This  is  the  software  architecture  level  of  design.  There  is  a  considerable  body  of  work 
on  this  topic,  including  module  interconnection  languages,  templates  and  frameworks  for 
systems  that  serve  the  needs  of  specific  domains,  and  formal  models  of  component  integration 
mechanisms.  However,  there  is  not  currently  a  consistent  terminology  to  characterize  the 
common  elements  of  these  fields.  Instead,  many  architectural  structures  are  described  in 
terms  of  idiomatic  patterns  that  have  emerged  informally  over  time.  For  example,  typical 
descriptions  of  software  architectures  include  statements  such  as: 

-  “Camelot  is  based  on  the  client-server  model  and  uses  remote  procedure  calls  both 
locally  and  remotely  to  provide  communication  among  applications  and  servers.”  [S*87]. 

-  "Abstraction  layering  and  system  decomposition  provide  the  appearance  of  system 
uniformity  to  clients,  yet  allow  Helix  to  accommodate  a  diversity  of  autonomous  devices. 
The  architecture  encourages  a  client-server  model  for  the  structuring  of  applications.” 
[F0851 

-  "We  have  chosen  a  distributed,  object-oriented  approach  to  managing  information." 
[Lin871 

-  "The  easiest  way  to  make  the  canonical  sequential  compiler  into  a  concurrent  compiler  is 
to  pipeline  the  execution  of  the  compiler  phases  over  a  number  of  processors. ...  A  more 
effective  way  (is  to)  split  the  source  code  into  many  segments,  which  are  concurrently 
processed  through  the  various  phases  of  compilation  (by  multiple  compiler  processes] 
before  a  final,  merging  pass  recombines  the  object  code  into  a  single  program.”  [S*88] 

Other  software  architectures  are  carefully  documented  and  often  widely  disseminated. 
Examples  include  the  International  Standard  Organization’s  Open  Systems  Interconnection 
Reference  Model  (a  layered  network  architecture)  [Pau85],  the  NIST  CASEE  Reference 
Model  (a  generic  software  engineering  environment  architecture)  [Eai90],  and  the  X  Window 
System  (a  windowed  user  interface  architecture)  (SG86]. 


It  is  increasingly  clear  that  effective  software  engineering  requires  facility  in  architec¬ 
tural  software  design.  First,  it  is  important  to  be  able  to  recognize  common  paradigms  so  that 
high-level  relationships  among  systems  can  be  understood  and  so  that  new  systems  can  be 
built  as  variations  on  old  systems.  Second,  detailed  understanding  of  software  architectures 
allows  the  engineer  to  make  principled  choices  among  design  alternatives.  Third,  an  archi¬ 
tectural  system  descnpuon  is  often  essential  to  the  analysis  and  description  of  the  high-level 
properties  of  a  complex  system.  Fourth,  fluency  in  the  use  of  formal  notations  for  describing 
architectural  paradigms  allows  the  software  engineer  to  communicate  new  systems  designs 
to  others. 

Regrettably,  software  architectures  receive  little  or  no  systematic  treatment  in  most  ex¬ 
isting  software  engineering  curricula,  either  undergraduate  or  graduate.  At  best,  students  are 
exposed  to  one  or  two  specific  application  architectures  (such  as  for  a  compiler  or  for  pans  of 
an  operating  system)  and  may  hear  about  a  few  other  architectural  paradigms,  but  no  serious 
attempt  is  made  to  develop  comprehensive  skills  for  understanding  existing  architectures 
and  developing  new  ones.  This  results  in  a  serious  gap  in  current  curricula:  students  are 
expected  to  learn  how  to  design  complex  systems  without  the  requisite  intellectual  tools  for 
doing  so  effectively. 

We  have  developed  a  course  to  bridge  this  gap.  This  course  brings  together  the  emerging 
models  for  software  architectures  and  the  best  of  current  practice.  It  examines  how  to 
approach  systems  from  an  architectural  point  of  view.  Other  curriculum  proposals  have 
touched  on  this  subject,  but  to  our  knowledge  this  is  the  first  implementation  of  a  full  course 
in  the  area. 

3  Philosophy  and  Course  Overview 

3.1  Objectives 

We  designed  a  course  for  senior  undergraduates  and  students  in  a  professional  master’s 
program  for  software  engineering.  By  the  end  of  this  course,  students  should  be  able  to: 

-  Recognize  major  architectural  styles  in  existing  software  systems. 

-  Describe  an  architecture  accurately. 

-  Generate  reasonable  architectural  alternatives  for  a  problem  and  choose  among  them. 

-  Construct  a  medium-sized  software  system  that  satisfies  an  architectural  specification. 

-  Use  existing  definitions  and  development  tools  to  expedite  such  tasks. 

-  Understand  the  formal  definition  of  a  number  of  architectures  and  be  able  to  reason 
precisely  about  the  properties  of  those  architectures. 

-  Understand  how  to  use  domain  knowledge  to  specialize  an  architecture  for  a  particular 
family  of  applications. 

33  Approach 

We  believe  that  important  skills  for  designing  complex  systems  can  be  provided  by  a  course 
that  examines  systems  from  an  architectural  point  of  view.  Specifically,  our  course  consid¬ 
ers  commonly-used  software  system  structures,  techniques  for  designing  and  implementing 
these  structures,  models  and  formal  notations  for  characterizing  and  reasoning  about  archi¬ 
tectures,  tools  for  generating  specific  instances  of  an  architecture,  and  case  studies  of  actual 


system  architectures.  It  teaches  the  skills  and  background  students  need  to  evaluate  the 
underlying  architecture  of  existing  systems  and  to  design  new  systems  in  principled  ways 
using  well-founded  architectural  paradigms. 

Since  this  is  an  entirety  new  course  rather  than  a  modification  of  an  existing  course, 
the  major  challenge  in  its  development  was  to  define  and  delimit  its  intellectual  content. 
While  the  ability  to  recognize  and  use  software  architectures  is  essential  for  the  practicing 
software  engineer,  there  is  to  date  no  codified  body  of  knowledge  that  deals  specifically  with 
this  subject.  Rather,  relevant  material  is  scattered  over  published  case  studies,  standards 
repons,  formal  models,  informal  system  documentation,  and  anecdotal  experience.  We  have 
collected  many  of  these  sources,  distilled  them  into  a  corpus  of  presentable  knowledge, 
and  discovered  ways  to  make  that  knowledge  directly  usable  by  university  students  and  the 
software  engineering  community  at  large. 

Our  approach  focuses  on  developing  four  specific,  related  topic  areas: 

Classification:  In  order  to  use  software  architectures,  it  is  first  necessary  to  be  able  to 
recognize  an  architectural  style  and  to  describe  a  system  in  terms  of  its  architecture.  The 
tools  required  to  describe  and  categorize  common  architectural  models  include  notations 
for  defining  architectures  and  a  taxonomy  of  existing  models.  In  addition  to  introducing 
the  student  to  these  tools,  this  topic  addresses  the  problem  of  architectural  selection 
to  solve  a  given  software  engineering  problem.  It  covers  both  high-level  architectural 
idioms  (e.g.,  pipeline  architectures)  and  specific  reference  models  (e.g..  the  OSI  layered 
model). 

Analysis:  Effecuve  use  of  a  software  architecture  depends  on  the  ability  to  understand  and 
reason  about  us  properties  (such  as  functional  behavior,  performance,  developmental 
flexibility,  evolvability,  and  real-time  behavior).  Such  analysis  can  be  applied  to  many 
kinds  of  architectural  description,  but  it  is  particularly  effective  in  the  context  of  formal 
descriptions,  where  the  power  of  mathematics  can  be  exploited.  This  topic  therefore 
covers  techniques  for  analyzing  an  architecture.  It  introduces  students  to  formal  and 
informal  methods  and  illustrates  the  ways  in  which  formal  analysis  can  be  used  to 
evaluate  and  select  among  architectural  alternatives  [Fi87]  [GD90]. 

Tools:  Certain  architectures  have  evolved  to  the  point  where  there  is  system  support  for 
defining  applications  using  diem  and  for  executing  those  applications  once  they  are 
built  Examples  include  Unix  supportfor  single-stream  pipelinearchitectures.  compilers 
for  module  interconnection  languages  (such  as  Ada  package  specifications),  and  IDL 
(Interface  Description  Language)  readers  and  writers  for  shared  data.  Facility  with 
such  toots  is  a  valuable  skill  for  using  the  supported  architectures  in  the  context  of 
current  technology.  Moreover,  existing  tools  provide  good  illustrations  of  the  kinds  of 
automated  support  that  we  can  expect  to  become  pervasive  as  the  field  becomes  more 
fully  developed  and  populated  with  useful  architectures. 

Domain-Specific  Architectures:  Specific  knowledge  about  an  application  domain  can  im¬ 
prove  the  power  of  the  notations  and  tools  for  constructing  systems  in  that  domain.  The 
same  holds  true  for  architectures,  and  there  is  active  research  and  industrial  development 
in  the  area  of  domain-specific  software  architectures  [DSS90].  The  course  looks  at  a 
number  of  these  to  understand  how  domain  knowledge  can  be  exploited  in  designing  an 
architecture  tailored  to  a  specific  application  family. 

We  rely  heavily  on  case  studies  in  each  of  these  topic  areas.  These  are  used  to  motivate 
the  importance  and  scope  of  architectural  approaches,  illustrate  what  has  been  done  so  far. 


and  give  students  models  for  creaung  architectural  descriptions  of  their  own.  In  addition  to 
examining  existing  case  studies,  students  are  expected  to  carry  out  a  significant  case  study 
of  their  own.  By  doing  this  they  practice  applying  the  techniques  of  architectural  description 
and  analysis  and  contribute  to  the  field  by  adding  to  the  body  of  carefully  documented 
architectural  descriptions. 

4  Course  Description 

In  this  section,  we  give  an  overview  of  each  topic  covered  in  the  course.  This  information  is 
summarized  in  Figure  1 .  Each  row  of  the  figure  contains  the  lecture  number,  the  major  topic 
and  subtopic  covered  in  the  lecture  (as  described  below),  the  reading  which  the  student  is  to 
have  completed  prior  to  attending  the  lecture,  and  the  homework  assignment  (if  any)  to  be 
discussed  or  turned  in  on  that  date.  The  assignments  are  numbered  A1  through  A4,  with  the 
course  project  due  at  the  end  of  the  semester.  These  are  discussed  in  sections  4.3  through 
4.5. 

Introduction  (2  lectures) 

-  Orientation.  What  is  the  architectural  level  of  software  design,  and  how  does  it  differ 
from  intra-module  programming?  Overview  of  the  course. 

-  What  is  a  Software  Architecture?  Constructing  systems  from  modules.  Some  familiar 
kinds  of  architectures.  Some  common  kinds  of  modules.  [Sha90b,  DK76,  PW91] 

Architectural  Idioms  (5  lectures) 

-  Objects.  Information  hiding,  abstract  data  types,  and  objects.  Organizing  systems  by 
encapsulating  design  decisions,  or  "keeping  secrets  ”  [PCW85,  B0086,  WBJ90] 

-  Pipes  Events.  Two  architectural  idioms:  pipes  and  event  systems.  Pipes  support  a 
dataflow  model.  Event  systems  support  loosely-coupled  components  interacting  via 
event  broadcast.  [Par72,  GKN88] 

-  Multi-process  Systems.  Organizing  systems  as  collections  of  independent  computations 
that  run  cooperatively  on  one  or  many  processors.  [And91] 

-  Blackboards.  Sharing  complex  knowledge  about  a  problem;  making  progress  when  you 
can't  tell  in  advance  what  order  to  impose  on  the  subproblems.  (Nii86a.  Nii86b] 

-  Heterogeneous  Design.  Designers  don't  have  to  limit  themselves  to  a  single  architectural 
idiom.  Examples  of  systems  that  use  several  idioms  at  various  places  in  the  system. 
[Sha90a,  Sha91] 

Module  Interconnection  Languages  (4  lectures) 

-  Classical  MILS.  Historically,  the  earliest  large  systems  were  developed  in  procedural 
languages.  The  most  common  of  the  MILs  reflect  this  in  their  emphasis  on  importing  and 
exporting  names  of  procedures,  variables,  and  a  few  other  constructs.  (PDN86,  LS79] 

-  Unix  Pipes.  The  Unix  paradigm  connects  independent  processes  by  data  flow.  The 
organization  of  the  processes  and  the  style  and  tools  for  connection  are  substantially 
different.  [Bac86] 
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Subtopic 


Reading 
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1 

Introduction 

Orientation 

2 

What  is  a  SW  Arch? 

[Sha90h.  DK76,  PW91] 

3 

Architectural 

Objects 

[PCW85.  B0086,  WBJ90] 

4 

Idioms 
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5 
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6 
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7 
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8 
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9 
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10 
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[H*88.  T83] 

U 

Augmentations 
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12 

Formal  Models 
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[Spi89b,  Sha85] 

13 

Industrial  Experience 
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14 
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15 

Event  Systems 
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16 
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17 

Domain-Specific  Data  Processing 
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Flg.l.  Summary  of  Course  Topics 


-  Module  Interconnection  in  Standard  ML  and  Ada.  An  important  property  of  modern 
module  interconnection  languages  is  the  ability  to  parameterize  modules.  This  is  repre¬ 
sented  l>>  generics  in  Ada  and  functors  in  SML.  [H*88,  T83] 

_  Augmentations  to  Module  Interfaces.  Future  prospects  for  module  interconnection.  How 
to  augment  a  module’s  interface  so  that  it  conveys  more  than  signatures.  (Pcri$7,  Gro91] 

Formal  Models  of  Software  Architecture  (5  lectures) 

-  Introduction  to  Z.  Basic  notation  of  the  Z  Specification  Language.  The  schema  calculus. 
[Spi89b.  Sha8S] 

_  industrial  Experience  with  Formal  Models.  Use  of  formal  models  to  understand, 
document,  and  analyze  system  architectures  in  two  major  industrial  case  studies. 
[GD90.HK91) 

-  Paisley.  Executable  specification  language  that  supports  some  elementary  performance 
analysis.  [Zav911 


-  Event  Systems.  Formal  model  of  event  systems.  Specialization  of  abstract  formal  models 
to  describe  specific  systems.  IGN91] 

-  Pipes  and  Filters.  Abstract  model  of  pipes  and  filters.  Use  of  formalism  to  explain  what 
a  software  architecture  is  and  to  analyze  its  properties.  [AG92] 

Domain-Specific  Architectures  <5  lectures) 

-  Data  Processing.  Architectures  for  management  information  systems.  [Fis91,  RC86] 

-  Distributed,  Heterogeneous  Computing.  Applied  pipe  and  filter  architectures.  Architec¬ 
tures  to  support  flexible  processor  allocation  and  reconfiguration.  [BWW88,  D*91] 

-  Real-Time  System  Architectures.  Real-time  schedulers:  rate- monotonic  scheduling , cyclic 
executives,  and  others.  Conditions  under  which  a  particular  real-time  architecture  can 
be  applied.  (SG90.  Sta881 

-  Architectures for  Mobile  Robotics.  Software  organization  of  reactor-effector  systems  that 
operate  in  an  uncertain  environment  The  CMU  task  control  architecture.  [HR90,  SST86] 

-  Layered  Architectures  for  Communication.  Network  protocols  based  on  layered  model 
of  communication  abstractions.  Special  emphasis  on  ISO  Open  System  Interconnection 
(OSI)  standard.  (Tan8 1  ] 

Tools,  Environments,  and  Automated  Design  Guidance  (5  lectures) 

-  Hints  on  System  Design.  Sage  guidance  and  rules  of  thumb  about  designing  good 
systems.  [Lam84] 

-  Automated  Design  Guidance.  The  selection  of  a  software  architecture  should  depend  on 
the  requirements  of  the  application.  This  example  of  a  system  shows  how  to  make  the 
structural  design  of  a  user  interface  explicitly  dependent  on  the  functional  requirements. 
[Lan90] 

-  Architecture  Transformers.  Semi-automatic  conversion  of  the  uniprocessor  version  of 
a  system  to  a  multiprocesor  version;  not  fully  general,  but  works  under  clearly  stated 
conditions.  [Bis87,  BAP871 

-  System  Generators.  Automatic  production  of  certain  classes  of  systems  from  their 
specifications.  fLS86.  Joh86,  B091] 

-  Environment  Generators.  Automatic  production  of  environments  from  descriptions  of 
the  tasks  to  be  performed.  (HGN91] 

5  Assignments 

5.1  Purpose 

The  purpose  of  the  assignments,  as  in  any  course,  is  to  help  students  master  the  material. 
Assignments  serve  the  additional  purpose  of  demonstrating  the  students’  mastery  of  the 
material,  thereby  establishing  a  basis  for  evaluation. 

Students  begin  by  examining  and  understanding  existing  work  in  the  area.  Then  they 
apply  what  they’ve  seen  and  heard,  first  by  trying  to  emulate  it  and  then  by  performing 
analysis.  Three  kinds  of  assignments  lead  students  through  these  activities. 

First,  the  course  is  organized  around  written  papers  and  lectures  that  present  and  interpret 
this  material.  We  believe  that  the  lectures  are  most  useful  if  they  provide  interpretation. 


explanation,  and  additional  elaboration  of  material  students  have  already  read  and  thought 
about.  In  addition  to  assigning  readings,  we  provide  guidance  about  the  important  points  to 
read  for  and  questions  to  help  students  focus  on  the  most  significant  points  in  the  reading. 

Secor four  two-week  assignments  ask  students  to  apply  the  lecture  material.  Three  of 
thesv  ^asignments  require  students  to  develop  small  software  systems  in  specific  architectural 
styles.  The  fourth  is  a  formal  analysis  task,  which  allows  the  students  to  work  with  a  specific 
architectural  formalism. 

Third,  students  examine  existing  software  systems  to  determine  their  architectures. 
We  identified  several  systems  of  about  20  modules.  For  the  final  project  of  the  course, 
each  student  team  analyzed  the  actual  system  structure  of  one  of  these  and  interpreted  the 
designer's  architectural  intentions. 

We  organized  the  students  into  teams  of  two  (with  one  team  of  three  because  an  odd 
number  of  students  enrolled).  This  encouraged  students  to  enhance  their  understanding 
through  discussions  with  another  student,  reduced  the  amount  of  overhead  required  of  any 
one  student  to  get  to  the  meat  of  a  problem,  and  allowed  us  to  partially  compensate  for 
differences  in  programming  language  and  other  related  experience.  The  course  included 
both  undergraduate  students  and  students  in  the  Master  of  Software  Engineering  program: 
to  the  extent  possible  we  paired  undergraduates  with  g  id  nates  so  that  their  experience  would 
complement  each  other. 

Since  students  often  tend  to  spend  most  of  their  attention  and  energy  on  the  components 
of  a  course  that  contribute  to  the  final  grade,  we  used  the  allocation  of  credit  as  a  device 
to  focus  them  on  the  most  important  activities.  To  this  end,  we  included  four  factors  in  the 
grading  basis.  Here  is  the  description  of  these  factors  as  stated  in  the  initial  course  handout: 


-  Readings:  <25%)  Each  lecture  will  be  accompanied  by  one  or  more  readings,  which  we 
expect  you  to  read  before  you  come  to  class,  lb  help  you  focus  your  thoughts  on  the 
main  points  of  the  reading  we  will  assign  a  question  to  be  answered  for  each  of  the 
reading  assignments.  Each  question  should  be  addressed  in  less  than  a  page,  due  at  the 
beginning  of  the  class  for  which  it  is  assigned.  Each  of  these  will  be  evaluated  on  a 
simple  ok/noi-ok  basis  and  will  count  for  about  1%  of  your  grade. 

-  Homework  Assignments:  <40%)  There  will  be  four  homework  assignments.  Each  will 
count  10%  of  your  grade.  The  first  three  will  be  system-building  exercises.  Their  purpose 
is  to  give  you  some  experience  using  architectures  to  design  and  implement  real  systems. 
You  will  work  in  groups  of  two  (assigned  by  us)  to  carry  out  each  assignment  lb  help 
clarify  your  designs  we  will  hold  a  brief,  un-graded  design  review  for  each  assignment 
during  class  a  week  before  it  is  due.  Groups  will  take  turns  presenting  their  preliminary 
designs  and  getting  feedback  from  the  class  and  instructors.  The  fourth  assignment  will 
give  you  some  practice  using  formal  models  of  software  architectures. 

-  Project:  (25%)  There  will  be  a  course  project,  designed  to  give  you  some  experience  with 
the  architecture  of  a  substantial  software  system.  You  will  analyze  an  existing  software 
system  from  an  architectural  point  of  view,  document  your  analysis,  and  present  the 
results  to  the  rest  of  the  class.  Your  grade  will  depend  both  on  the  quality  of  your 
analysis  and  also  on  the  presentation  of  that  analysis. 

-  Instructors'  judgement:  (10%) 


5.2  Readings 


No  textbook  exists  for  this  course.  Background  material  for  the  course  consisted  of  readings, 
primarily  from  professional  journals,  selected  to  complement  the  lectures  and  discussions. 
The  objective  was  for  every  student  to  read  each  paper  before  the  corresponding  class  lecture. 

To  ensure  this,  a  short  homework  assignment  was  set  for  each  class.  Each  homework 
consisted  of  a  few  quesuons  to  be  answered  about  the  readings.  These  assignments  were 
due  at  the  beginning  of  the  corresponding  lecture  and  discussion.  Though  the  single  grade 
attached  to  a  particular  assignment  would  not  significantly  affect  the  course  grade,  the 
cumulative  effect  of  these  individual  grades  resulted  in  significant  weight  being  placed  on 
the  readings. 

A  beneficial  side  effect  of  this  policy  was  that  it  obviated  the  need  for  examinations.  The 
incremental  learning  process  was  monitored  and  reinforced  by  the  assignments,  so  there  was 
no  need  for  a  final  exam  to  measure  student  progress.  As  a  result,  end-of-semester  energy 
could  be  productively  directed  to  the  course  project. 

Each  reading  was  accompanied  by  hints  which  identified  points  to  look  for  in  each  paper 
and  gave  advice  on  pans  to  ignore.  These  hints  helped  students  to  focus  on  the  important 
concepts  in  each  paper,  and  were  particularly  important  because  of  the  wide  variety  of 
notations  and  languages  introduced  in  the  readings. 

Here  are  some  examples  of  the  hints  we  gave: 

-  In  these  readings  you  will  be  exposed  to  many  different  languages.  You  should  not  try  to 
team  the  specific  syntax  of  each  language,  nor  should  you  memorize  the  specific  features 
of  each  language.  Rather,  you  should  try  to  get  a  feei  for  the  design  space  of  module 
interconnection  languages — what  it  is  possible  to  represent  and  what  it  is  desirable  to 
represent 

-  First  and  foremost,  read  to  understand  the  blackboard  model  and  the  kinds  of  problems 
for  which  it  is  appropriate.  Study  Hearsay  and  HASP  to  see  how  the  model  is  realized  in 
two  rather  different  settings.  Look  at  the  other  examples  to  see  the  range  of  variability 
available  within  the  basic  framework. 

The  questions  for  each  assignment  also  played  an  important  role  in  focusing  the  intellec¬ 
tual  energies  of  the  students.  The  quesuons  were  structured  to  have  the  students  understand 
the  concepts  involved,  rather  than  simply  read  to  complete  the  homework.  Since  the  reading 
and  homework  combined  were  intended  to  take  only  a  couple  of  hours,  the  questions  dealt 
with  major  points  and  did  not  require  deep  thought  or  analysis. 

Here  are  some  examples  of  the  questions  we  asked: 

-  What  are  the  essential  differences  between  the  architectural  style  advocated  by  Pamas 
and  that  advocated  by  Gar lan,  Kaiser,  and  Notion? 

-  What  abstract  data  type  does  a  pipe  implement?  What  common  implementation  of  that 
abstract  data  type  is  used  to  implement  pipes? 

-  What  is  the  problem  addressed  by  sharing  specifications  in  SML?  Why  doesn’t  this 
come  up  with  Ada  generics? 

-  What  are  the  major  abstracuons  of  an  interconnection  model?  How  are  these  specialized 
in  the  unit  and  syntactic  models? 


S3  Architectural  Development  Tasks 

Believing  that  one  must  constructively  engage  a  style  to  understand  it,  we  assigned  pro¬ 
gramming  tasks  in  three  different  architectural  idioms.  For  each  task,  we  supplied  an  imple¬ 
mentation  in  the  required  idiom  that  used  several  components  from  an  available  collection. 
The  assignment  required  students  to  extend  the  implementation  in  the  same  style  by  recon¬ 
necting  parts,  using  other  components,  or  minimally  changing  components.  The  choice  of 
this  format  was  driven  by  two  guiding  principles: 

-  The  attenuon  of  the  students  should  be  focused  at  the  architectural  level  rather  than  at 
the  algorithms-and-data-structures  level.  (Students  should  already  know  how  to  do  the 
latter.) 

-  It  is  unreasonable  to  expect  the  accurate  use  of  an  unfamiliar  idiom  without  providing 
illustrative  sample  code  employing  that  idiom. 

A  pleasant  side-effect  of  this  choice  of  format  was  that  problems  more  closely  resembled 
software  maintenance/reuse  than  building  a  system  from  scratch.  In  addition,  we  were  faced 
with  a  considerable  diversity  of  programming  language  background  among  the  students.  It's 
easier  to  work  in  an  unfamiliar  language  if  you  have  a  working  starting  point. 

To  encourag.  cooperation  and  to  balance  unfamiliarity  with  particular  programming 
languages  and  systems,  students  worked  in  pain  on  the  programming  tasks.  However,  each 
task  had  a  set  of  questions  to  be  answered  individually. 

A  major  objecuve  of  this  course  is  for  students  to  leave  with  an  understanding  of  the 
essential  features  of  a  given  problem  that  make  a  particular  architectural  choice  appropriate 
or  inappropriate.  To  do  this,  we  assigned  variations  of  a  single  core  problem  for  all  three 
tasks,  differing  primarily  in  the  features  related  to  the  choice  of  idiom.  By  assigning  the 
same  basic  problem  for  each  architectural  idiom,  we  avoided  the  risk  of  students  associating 
problem  class  X  with  architectural  idiom  Y,  instead  promoting  understanding  of  the  features 
of  each  problem  that  should  lead  the  designer  to  choose  that  idiom.  By  varying  the  features 
related  to  the  architectural  choice,  we  also  discouraged  students  Grom  leaving  each  solution 
in  the  same  basic  architectural  idiom,  adding  only  the  superficial  trappings  of  the  second 
idiom.  For  example,  by  changing  the  requirements  on  the  system,  we  ensured  that  an  event- 
driven  solution  would  not  merely  be  a  pipes  &  filters  solution  “dressed  up”  to  look  like  an 
event-driven  system. 

Because  the  problems  involved  not  only  the  production  of  a  working  system  but  also  the 
analysis  of  an  architectural  style,  we  held  design  reviews  halfway  through  each  assignment. 
These  reviews  were  presented  by  the  students  in  the  class,  with  each  team  making  one 
presentation  sometime  during  the  semester.  The  reviews  were  not  graded;  they  thereby 
provided  a  means  for  the  class  to  engage  in  discussions  about  the  architectural  style  and  for 
the  instructors  to  guide  the  student  solutions  (both  those  being  presented  and  those  of  the 
students  watching  the  presentation)  by  asking  pointed  questions.  These  presentations  were 
performed  during  class  time,  and  their  schedule  is  presented  in  Figure  1. 

The  core  task  chosen  was  the  KWIC  indexing  problem [Paf7 2,  GKN88].  In  this  problem, 
a  set  of  lines  (sequences  of  words)  is  extended  to  include  all  circular  shifts  of  each  line,  and 
the  resulting  extended  set  is  alphabetized.  This  core  problem  was  varied  in  each  architectural 
idiom  as  follows: 

Object-Oriented:  This  variation  was  interactive,  a  user  enters  lines  one  at  a  time,  inter¬ 
spersed  with  requests  for  the  KWIC  index.  Students  were  supplied  with  a  system  which 


generated  the  KW1C  index  without  the  circular  shifts  (i.e.,  a  line  alphabetize^  and  asked 
to  include  the  shifts.  In  addition,  students  were  asked  to  omit  lines  which  began  with  a 
“trivial”  word  (e.g..  and  or  the). 

Pipes  &  Filters:  in  this  variation,  students  were  asked  to  generate  a  batch  version  which 
generated  KWIC  indices  of  login  and  user  names  (as  generated  by  the  finger  command). 
Students  carried  out  two  tasks.  In  one  task,  students  used  the  Unix  shell  to  connect 
“modules”  such  as  the  common  Unix  commands  finger,  sort,  and  unit}.  A  second  task 
required  them  to  connect  the  same  modules  in  a  pipe  organization  too  complex  to 
describe  in  the  shell,  so  that  they  had  to  use  raw  pipes  from  within  C.  As  before,  they 
began  with  solutions  which  alphabetized  lines  but  did  not  generate  circular  shifts. 
Event-driven  (implicit  invocation):  This  variation  extended  the  problem  for  the  object- 
oriented  architecture  with  a  delete  command.  Students  were  required  to  reuse  existing 
modules,  augmenting  them  with  event  bindings  to  establish  how  they  communicated. 

5.4  Formal  Modelling 

To  develop  skill  in  understanding  and  manipulating  formal  models  we  assigned  a  task  that 
required  students  to  extend  an  existing  formal  model  of  a  software  architecture. 

As  with  the  architectural  development  tasks  the  formal  modelling  task  builds  on  an  ex¬ 
isting  base — in  this  case  the  formal  model  developed  by  Garlan  and  Notkin  of  event  systems 
[GN91].  In  this  work  the  authors  showed  how  a  simple  model  of  systems  based  on  event 
broadcast  could  be  specialized  for  a  number  of  common  systems,  including  Smalltalk  MVC, 
Gandalf  programming  environments,  the  Field  programming  environment,  and  APPL/A. 

The  students  were  asked  to  perform  similar  specializations  for  two  different  architectures: 
spreadsheets  and  blackboard  systems.  In  addition,  they  were  asked  to  provide  a  commentary 
that  answered  the  following  questions: 

1 .  What  important  aspects  of  the  modelled  architectures  are  (intentionally)  left  out  of  the 
model? 

2.  For  the  blackboard  system,  would  it  be  possible  to  model  some  notion  of  “non¬ 
interference"? 

3.  For  the  spreadsheet  system,  is  the  Circular  property  defined  in  the  events  paper  a  useful 
concept?  Why  or  why  not? 

4.  Based  on  the  formal  models,  briefly  compare  each  of  the  two  new  systems  with  the 
other  ones  that  were  formally  modelled.  For  example,  you  might  explain  which  of  the 
other  systems  are  they  most  similar  to. 

5.5  Analysis  and  Interpretation  of  a  System 

In  addition  to  the  assignments  described  above,  students  also  examined  and  described  the 
architecture  of  a  non-trivial  system.  About  midway  through  the  semester  we  asked  each 
group  of  students  to  select  a  system  from  a  list  of  candidates  that  we  supplied.  Alternatively, 
students  could  volunteer  a  system  of  their  own,  provided  it  met  the  criteria  outlined  below. 

The  students’  task  was  to  complete  an  architectural  analysis  of  the  chosen  system  by  the 
end  of  the  semester.  This  analysis  was  required  to  include  the  following  components: 

1.  Parts  catalog:  A  list  of  the  modules  in  the  system,  making  the  interfaces  explicit, 
together  with  an  explanation  of  what  each  one  does. 


2.  Interconnections  catalog:  A  list  of  the  connections  between  modules  together  with  a 
descriptions  of  each. 

3.  Architectural  description:  A  description  of  the  system’s  architecture,  using  the  vocab¬ 
ulary  developed  in  the  course. 

4.  Critique:  An  evaluation  of  how  well  the  architectural  documentation  for  the  system 
matches  the  actual  implementation. 

5.  Revision:  Suggestions  for  ways  that  the  system  architecture  could  have  been  improved. 

In  addition  to  a  written  analysis  students  were  expected  to  present  their  analysis  to  the 
class.  We  allotted  three  days  at  the  end  of  the  semester  for  this.  The  grade  on  the  project  was 
determined  both  by  the  written  analysis  and  the  presentation. 

In  selecting  candidate  systems  we  attempted  to  find  systems  that  are  tractable  but  chal¬ 
lenging.  Specifically,  we  applied  the  following  criteria  for  selection: 

-  Size:  Ten  to  twenty  modules  containing  between  2,000  and  10,000  lines  of  code. 

-  Documentation:  It  should  have  enough  system  documentation  that  students  do  not  need 
to  start  (Tom  raw  code  to  do  their  analysis. 

-  Resident  guru:  There  should  be  someone  in  the  local  environment  who  knows  the 
system  and  can  answer  questions  about  its  design  and  implementation. 

6  Evaluation 

6.1  Lessons  from  the  Initial  Offering 

The  first  offering  of  the  course  ran  during  the  spring  semester  of  the  199 1- 1 992 academic  year 
at  Carnegie  Mellon  University.  Four  undergraduate  students  ami  seven  Master  of  Software 
Engineering  students  took  the  course.  There  were  also  half  a  dozen  regular  auditors.  The 
lessons  we  have  learned  as  a  result  of  that  offering  are  based  upon  the  students’  progress  in 
learning  the  course  material  and  on  evaluation  of  the  course  by  the  students  themselves. 

Content.  It  is  clear  that  a  sufficiently  large  body  of  knowledge  exists  to  support  a  course 
in  software  architecture.  When  we  designed  this  version  we  were  unable  to  include  all  the 
topics  of  interest,  and  we  made  some  had  decisions  among  alternative  materials  for  the 
topics  we  did  include. 

The  specific  topics  of  the  course  had  varying  success.  The  section  on  architectural  idioms 
was  particularly  valuable.  While  the  section  on  MILs  was  important  to  have  included  in  the 
course,  we  now  feel  we  spent  too  much  time  on  that  topic.  Two  lectures  would  have  been 
more  appropriate  than  the  four  that  we  scheduled.  The  formal  methods  segment  worked 
out  well,  but  for  students  with  no  exposure  to  Z,  it  required  considerably  more  effort  than 
the  other  sections.  (Almost  all  of  the  master’s  level  students  had  already  had  a  course  in 
formal  methods.)  The  lectures  on  domain-specific  software  architectures  were  of  mixed 
value,  since  these  lectures  were  predominantly  given  by  invited  speakers.  The  section  on 
tools  and  environments  was  reasonably  successful,  but  suffered  from  the  fact  that  there  is 
relatively  little  material  directly  applicable  to  software  architectures. 

Many  of  the  readings  were  quite  good;  others  should  be  replaced.  The  best  of  the 
readings  included  Nii’s  survey  of  Blackboard  Systems  (Nii86a,  Nii86b],  Andrews'  survey  of 
distributed  architectures  [And91],  Shaw's  overview  of  architectural  styles  [Sha90a],  Pamas’ 


classic  “Criteria”  [Par72]  and  A7  papers  [PCW85],  the  Perry  Inscape  paper  [Per87],  a  paper 
on  implicit  invocation  by  Garlan.  Kaiser,  and  Notkin  [GKN881,  Lamps  on’s  hints  on  system 
design  [Lam84],  and  Lane's  paper  on  the  concept  of  the  design  space  [Lan90],  The  course 
syllabus  would  have  been  much  better  if  we  had  been  able  to  find  good  readings  about  Unix 
pipes,  management  information  system  architectures,  the  ISO  Open  Systems  Interconnection 
model,  and  architectural  tools.  We  would  also  like  to  find  readings  about  object-oriented 
systems  that  deal  specifically  with  architectural  issues,  rather  than  programming  issues. 

The  assignments  that  involved  construction  and  analysis  of  systems  were  generally  quite 
valuable,  as  they  gave  students  practice  in  applying  the  principles  of  the  course.  However,  we 
felt  that  we  could  have  chosen  tasks  that  would  have  both  challenged  the  students  more  than 
we  did,  and  at  the  same  time  focused  on  some  of  the  more  important  issues  of  architectural 
design. 

Chosing  good  practical  problems  is  one  of  the  most  difficult  (and  important)  parts  of 
developing  such  a  course.  Part  of  the  problem  centers  around  finding  systems  that  are  of 
the  right  size  and  complexity.  On  the  one  hand,  it  is  important  to  find  systems  that  are  large 
enough  to  represent  nontrivial  architectures.  On  the  other  hand,  there  is  a  limit  to  the  size  of 
system  students  that  can  handle,  particularly  given  the  fact  that  we  wanted  students  to  have 
experience  with  several  architectures. 

Our  approach  to  the  problem  was  to  give  students  a  working  system  and  a  collection  of 
parts  that  they  could  reuse  and  modify  in  adapting  the  system  to  the  task  assigned.  Overall 
this  was  a  good  approach,  although  it  takes  a  lot  of  preparation  to  make  it  successful.  We 
attempted  to  use  Booch  components  [Boo87]  for  the  first  and  third  assignments,  and  the 
standard  Unix  tools  for  the  second  assignment  However,  many  of  the  software  needed  in 
the  solutions  to  the  problems  could  not  be  found  in  these  standard  collections.  As  a  result 
a  majority  of  the  code  in  the  starting  frameworks  was  developed  by  us  from  scratch.  For 
example  we  used  only  one  Booch  component  package  (a  total  of  200  lines),  but  wrote  1400 
lines  of  Ada  and  300  lines  of  C  for  the  frameworks  provided  to  the  students. 

Another  aspect  of  the  problem  of  chosing  good  assignments  is  to  find  problems  that 
exploit  the  target  architecture  but  do  not  have  a  single  solution.  Our  assignments  were  not 
sufficiently  rich  to  accomplish  this.  Moreover,  time  constraints  prevented  us  from  making 
more  parts  available  than  were  absolutely  required  for  the  assignments,  so  the  students  did 
not  face  the  challenge  of  selecting  an  architectural  solution  from  a  rich  pans  kit. 

One  issue  involving  the  assignments  was  the  use  of  multiple  programming  languages. 
We  wanted  to  avoid  giving  the  impression  that  there  is  a  one-to-one  mapping  between 
programming  languages  and  architectures.  However,  our  parts  kit  (the  Booch  components) 
was  in  Ada.  and  our  version  of  the  Ada  compiler  did  not  provide  a  library  for  manipulating 
Unix  pipes.  This  led  us  to  use  Ada  for  the  first  and  third  assignments,  and  C  for  the  second. 

Format  The  division  of  the  course  into  the  major  topics  had  some  advantages,  but  overall 
was  viewed  as  needing  revision.  The  course  lectures  touch  each  of  the  architectural  idioms 
three  times:  to  introduce  the  idiom,  to  examine  a  suitable  module  connection  language  or  tool, 
and  to  introduce  a  formal  model  and  analysis  technique  useful  within  the  idiom.  In  addition, 
some  idioms  reappear  in  domain-specific  examples.  In  retrospect,  a  course  organization  that 
factors  the  course  along  the  lines  of  architectural  idioms  seems  more  appropriate. 

We  were  pleased  to  teach  from  selected  readings.  The  readings  allowed  students  to  hear 
the  ideas  in  the  voices  of  their  creators.  Moreover,  we  believe  the  state  of  of  knowledge  in 


software  architectures  is  not  advanced  enough  to  provide  a  single  canonical  picture  of  the 
various  architectures.  Further,  we  were  able  to  order  the  topics  appropriately  to  meet  our 
ideas  of  how  the  topics  should  be  presented,  and  to  flexibly  schedule  the  guest  lecturers. 

The  chief  disadvantages  of  using  readings  as  source  material  are  that  notations  and 
terminology  vary  from  paper  to  paper,  and  that  the  architectural  significance  of  a  paper  may 
not  be  well  articulated.  It  is  also  a  nuisance  to  deal  with  copyright  considerations  (though 
many  of  the  papers  cany  blanket  permissions  for  educational  use). 

Assigning  questions  on  the  class  readings  was  a  good  idea.  It  served  both  to  focus 
students’  attention  and  to  encourage  them  to  do  the  reading  in  advance.  This  worked  well 
enough  that  we  could  plan  lectures  that  elaborated  and  interpreted  the  material  rather  than 
repeating  it. 

The  task  format  worked  well  in  terms  of  the  amount  of  time  allotted  and  overall  structure 
of  the  assignments.  However,  one  challenge  lay  in  the  diversity  of  language  experience 
among  the  students.  In  particular,  Ada  was  familiar  to  some  students,  but  new  to  others. 
While  this  course  was  not  intended  to  be  a  “programming  course,”  we  found  it  necessary 
to  provide  a  brief  Ada  help  session  for  students  without  Ada  experience.  This  session’s 
effectiveness  was  -limited  because  it  was  held  outside  normal  class  hours  and  was  not 
directly  graded.  Ideally  in  an  architectures  course,  however,  all  students  should  know  the 
programming  languages  to  be  used  for  the  assignments  prior  to  entering  the  class. 

Using  groups  to  accomplish  the  assignments  had  generally  positive  results.  By  mixing 
graduate  and  undergraduate  students  on  each  team,  the  teams  formed  a  balanced  collection 
of  strengths  which  enabled  them  to  grasp  the  essentials  of  the  programming  assignments 
quickly.  Also,  having  a  team  environment  allowed  the  students  to  discuss  the  architectural 
issues  among  themselves  in  a  more  structured  format  than  might  otherwise  have  been 
available.  We  believe  this  would  have  been  even  more  effective  if  a  more  challenging  set  of 
problems  were  presented. 

Comments  From  Students.  We  distributed  two  course  evaluations  to  students,  one  midway 
through  the  course  and  one  at  the  end.  Overall  student  responses  were  quite  positive.  Typical 
comments  were.  'Tve  noticed  that  I’m  viewing  problems  in  other  classes  from  a  different 
perspective.”  ,  and  “I  now  finally  understand  what  we  were  doing  when  we  built  that  system 
in  the  way  we  did.” 

At  a  more  detailed  level  the  students  felt  that  the  study  of  architectural  idioms  was  most 
important,  and  that  it  provided  a  foundation  for  a  body  of  knowledge  to  which  they  had 
not  been  exposed.  They  also  said  that  the  course  encouraged  a  new  perspective  on  software 
systems.  Some  students  wanted  more  emphasis  on  the  process  of  architectural  design  and 
guidance  in  choosing  an  architectural  idioms.  The  general  opinion  was  that  more  could  be 
added  to  the  course,  but  not  at  the  expense  of  current  material. 

The  readings  were  generally  viewed  as  a  valuable  pan  of  the  course.  Students  appreciated 
the  incentive  to  read  them  regularly,  and  they  particularly  appreciated  the  absence  of  a  final 
exam.  They  also  liked  having  lectures  serve  to  elaborate  the  readings  rather  than  repeating 
them — something  that  is  only  possible  when  the  instructor  can  assume  that  students  have 
actually  read  the  readings. 

The  course  required  a  significant  amount  of  work,  but  the  students  thought  it  was  worth 
the  effort  They  noted  that  unlike  most  courses,  the  load  is  fairly  level.  They  had  to  pay 
attention  to  the  course  regularly,  but  they  didn’t  wind  up  with  massive  deadline  crunches. 


The  team  orgamzauen  was  also  judged  favorably.  We  received  no  complaints  about 
unequal  workload  within  a  team,  although  some  team  members  commented  that  getting  a 
consensus,  even  on  a  small  team,  took  time. 

6 2  Changes  to  Consider 

While  we  are  generally  satisfied  with  the  course  as  taught,  we  see  some  areas  that  we  plan 
to  change  the  next  time  we  teach  the  course. 

Content.  While  the  course  did  not  suffer  from  a  lack  of  material,  a  number  of  areas  could 
be  added  to  the  curricultan.  In  particular,  study  of  heterogeneous  and  integrated  architectural 
idioms  would  be  appropriate,  as  would  more  study  and  practice  in  architectural  design  and 
decision  making.  One  way  that  room  could  be  made  for  this  material  is  by  reducing  the  time 
spent  on  module  interconnection  languages. 

Another  improvement  would  be  to  develop  a  more  consistent  terminology  in  our  lectures 
on  architectures.  Within  the  area  generally  termed  software  architecture,  there  is  a  bewilder¬ 
ing  diversity  of  terms  far  similar  concepts.  As  the  discipline  evolves  and  the  terminology 
stabilizes,  we  would  expect  this  problem  to  diminish. 

Format.  There  are  a  n amber  of  format  changes  which  we  believe  would  improve  the 
coherency  and  conceptual  integrity  of  the  course.  They  are: 

1 .  Concentrate  on  a  particular  idiom  for  a  span  of  3-4  lectures  to  give  the  students  a  deeper 
understanding  of  each  class  of  architecture.  A  consistent  format  for  the  study  of  each 
idiom  might  be: 

(a)  Introduction  of  idiom  and  survey  of  class 

(b)  Related  languages  or  tools 

(c)  Formal  model  * 

(d)  Case  study  and  analysis 

This  could  be  complemented  by  an  assignment  for  each  idiom,  to  give  a  single,  coherent 
presentation  of  an  architectural  style. 

2.  The  assignments  could  be  better  planned  to  emphasize  the  architectural  nature  of  the 
projects,  and  minimize  the  “hacking”  necessary  to  build  a  system.  Assignments  should 
allow  the  students  to  create  unsuccessful  solutions  as  well  as  different  but  successful 
solutions  to  the  same  problem.  More  emphasis  should  be  placed  on  analysis  of  the 
assignment,  encouraging  students  to  reflea  on  the  choices  made  and  the  reasons  for 
these  choices. 

The  only  way  we  see  to  create  reasonable  projects  is  to  provide  collections  of  ready¬ 
made  components.  Unfortunately,  reasonable  “pans  kits"  are  scarce,  and  most  existing 
parts  kits  do  not  clearly  illustrate  an  architectural  style.  Moreover,  in  many  cases  (such 
as  in  event  systems),  architectural  styles  require  tools  beyond  those  provided  even  by 
a  carefully  constructed  pans  kit.  This  infrastructure  is  likely  to  be  different  for  each 
architectural  style,  compounding  the  problem  when  multiple  architectural  styles  are 
presented.  Generally,  in  order  to  effectively  teach  multiple  architectural  styles  within 
the  constraints  of  a  single-semester  course,  we  need  architectural  tools  as  well  as  pans 
kits. 


3.  The  architectural  analysis  project  should  use  examples  that  are  familiar  to  the  instructors 
and  which  have  existing  architectural  documents  for  the  students  to  start  with. 

4.  The  reports  that  the  students  produce  from  the  architectural  analysis  project  should 
emphasize  the  high-level  structural  and  communications  paradigms  of  the  system,  rather 
than  specific  functionality  or  detailed  algorithmic  analysis.  To  this  end,  the  assignment 
of  the  project  should  specify  the  structure  of  the  report,  and  provide  good  examples  of 
existing  architectural  analyses. 

6  J  Conclusions  About  Teaching  Software  Architecture 

Software  architecture  is  worth  teaching.  It  can  be  taught  in  many  ways.  Based  on  our  experi¬ 
ence  with  the  present  course  and  previous  experience  with  four  semesters  of  graduate  reading 

seminars  in  the  area,  we  can  draw  some  conclusions  about  teaching  software  architecture  in 

any  format. 

-  Architecture  provides  a  bridge  between  theory  and  coding.  In  any  program  teaching 
system  design,  there  are  high  principles  of  program  construction  which  are  difficult 
to  relate  to  the  small  programming  assignments  that  comprise  the  majority  of  the 
undergraduate  experience.  A  course  that  presents  students  with  the  terminology  of 
software  architecture  and  that  gives  them  concrete  examples  of  systems  to  relate  to 
specific  architectural  styles  allows  the  students  to  relate  these  two  disparate  bodies  of 
information  more  readily  and  concretely. 

-  Students  seem  capable  of  rapidly  developing  an  aesthetic  about  architectures.  They 
can  identify  systems  in  their  own  experience  which  match  specific  styles,  and  they 
can  also  identify  flawed  designs  as  examples  of  poorly-formed  or  poorly-understood 
architectures.  They  are  quite  capable  of  answering  open-ended  questions  about  the 
appropriateness  of  a  specific  architecture  to  a  problem  and  defending  their  positions 
rationally  and  powerfully.  Unity  does  not  evolve  among  the  students,  however.  Different 
students  will  promote  different  architectures  for  the  same  problem,  depending  upon  their 
particular  points  of  view, 

-  There  is  little  concrete  material  available  in  any  form  to  guide  design  decisions.  Absent 
such  material,  students  get  little  help  in  resolving  point-of- view  differences.  Instructors 
should  make  every  effort  to  present  techniques  for  selecting  among  architectural  alter¬ 
natives.  including  even  simple  rules  of  thumb  such  as  “consider  an  interpreter  when 
you’re  designing  for  a  machine  that  doesn’t  actually  exist." 

-  There  is  enough  substantive  material  to  fill  a  course.  The  selection  we  made  for  this 
offering  was  based  on  the  coverage  of  our  graduate  reading  seminars.  However,  we 
recognize  that  there  were  a  number  of  difficult  choices  in  our  selection  which  might 
well  have  gone  another  way.  In  our  opinion,  the  field  of  software  architectures  is  moving 
from  a  point  where  finding  enough  papers  is  difficult  to  one  where  the  challenge  is  to 
select  the  appropriate  complement  of  papers. 

-  We  wish  there  were  more  organized  surveys  of  the  material  than  are  currently  present. 
Currently,  the  fragmented  nature  of  the  material  requires  that  the  students  be  carefully 
instructed  on  exactly  which  information  within  a  given  paper  is  appropriate  to  the 
subject  at  hand.  This  is  compounded  by  the  sheer  size  and  disorganization  of  the  current 
software  architectures  field.  There  are  few  papers  which  view  problems  from  a  purely 
architectural  perspective,  and  the  boundaries  between  architectural  idioms  are  not  a)  ways 


clear.  We  would  like  to  see  more  papers  presenting  architectural  analysis  techniques, 
and  more  worked  examples  in  specific  architectures.  We  would  also  like  to  see  more 
mature  distributed  systems  architectures  and  more  papers  like  Nil’s  [Nii86a,  Nii86b] 
that  survey  a  class  of  systems  against  a  single  architectural  paradigm.  We  think  this  will 
come  with  a  better  understanding  of  the  idioms  that  comprise  software  architecture. 

-  It  is  tempting  to  treat  the  subject  of  software  architectures  abstractly  and  present  only 
idealized  views  of  the  various  architectural  idioms.  Resist  this.  Students  have  weak 
intuitions  about  the  high-level  architectural  abstractions.  Every  formal  or  abstract  model 
must  be  related  to  a  real  example,  so  that  the  student  not  only  learns  the  abstract  view  of 
the  architecture,  but  also  the  characteristics  of  a  concrete  instance  of  that  architecture. 

-  Practice  in  using  models  is  important.  Analyzing  existing  architectures  without  working 
within  the  specific  architectural  framework  does  not  allow  the  student  to  recognize  the 
strengths  and  weaknesses  of  individual  architectural  styles.  It  is  not  sufficient  for  a 
student  to  be  able  to  recognize  a  specific  idiom;  the  student  must  also  be  able  to  decide 
which  idiom  to  apply  to  a  particular  problem.  For  that  skill,  analysis  alone  is  not  enough. 
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